inventory-service/build.gradle (2)

3-4: Spring Boot 버전 업데이트를 고려하세요.

payment-service와 동일하게 Spring Boot 3.1.5가 사용되고 있습니다. 보안 및 성능 개선을 위해 최신 버전으로 업그레이드를 권장합니다.

모든 서비스의 Spring Boot 버전을 일관되게 관리하기 위해 루트 build.gradle에서 버전을 중앙 관리하는 것을 고려하세요.

---

34-35: 동일한 데이터베이스 의존성 이슈가 있습니다.

payment-service와 동일하게 H2와 MySQL이 모두 runtime 의존성으로 포함되어 있습니다.

환경별로 데이터베이스 의존성을 분리하는 것을 권장합니다.

inventory-service/src/main/java/com/example/inventory/config/KafkaProducerConfig.java (1)

16-34: 동일한 이슈가 발견되었습니다.

이 파일은 delivery-service/src/main/java/com/example/delivery/config/KafkaProducerConfig.java와 동일한 구조를 가지고 있으며, 같은 문제점들이 있습니다:

1. 프로덕션 환경 필수 설정 누락 (acks, idempotence, retries 등)
2. 여러 서비스 간 설정 중복

앞서 delivery-service의 KafkaProducerConfig에 대한 리뷰 코멘트를 참고하여 동일한 개선사항을 적용하세요.

common/src/main/java/com/example/common/config/KafkaConsumerConfig.java (1)

38-38: 보안 위험: JsonDeserializer TRUSTED_PACKAGES="*" 사용 금지

와일드카드 신뢰 패키지 설정은 임의 클래스의 역직렬화를 허용하여 원격 코드 실행 공격에 노출될 수 있습니다. 이벤트 패키지로 제한해야 합니다.

-props.put(JsonDeserializer.TRUSTED_PACKAGES, "*");
+props.put(JsonDeserializer.TRUSTED_PACKAGES, "com.example.common.event");
+props.put(JsonDeserializer.USE_TYPE_INFO_HEADERS, true);

common/src/main/java/com/example/common/config/KafkaProducerConfig.java (1)

43-46: 선택사항: ProducerListener로 전송 실패 로깅 추가 고려

현재 KafkaTemplate은 기본 설정으로 생성됩니다. 프로덕션 환경에서 전송 실패를 추적하려면 ProducerListener를 추가하는 것이 좋습니다.

 @Bean
 public KafkaTemplate<String, Object> kafkaTemplate() {
-    return new KafkaTemplate<>(producerFactory());
+    KafkaTemplate<String, Object> template = new KafkaTemplate<>(producerFactory());
+    template.setProducerListener(new LoggingProducerListener<>());
+    return template;
 }

또는 각 서비스에서 send() 호출 시 ListenableFuture 콜백으로 처리할 수도 있습니다.

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

common/src/main/java/com/example/common/config/KafkaConsumerConfig.java (2)

38-38: 보안 위험: JsonDeserializer TRUSTED_PACKAGES="*" 사용 금지

와일드카드 신뢰 패키지는 폴리모픽 역직렬화 공격에 노출됩니다. 공용 이벤트 패키지로 제한하세요.

-props.put(JsonDeserializer.TRUSTED_PACKAGES, "*");
+props.put(JsonDeserializer.TRUSTED_PACKAGES, "com.example.common.event");

---

40-41: Saga 보상 트랜잭션에서 자동 커밋은 위험

메시지 처리 중 예외 발생 시에도 오프셋이 자동 커밋되어 보상 트랜잭션이 누락될 수 있습니다.

수동 커밋으로 변경하고 컨테이너 ACK 모드를 설정하세요:

-props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, true);
-props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, 1000);
+props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);

리스너 컨테이너 팩토리에 ACK 모드 추가:

 @Bean
 public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory() {
     ConcurrentKafkaListenerContainerFactory<String, Object> factory =
             new ConcurrentKafkaListenerContainerFactory<>();
     factory.setConsumerFactory(consumerFactory());
+    factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.RECORD);
     // 에러 핸들러 설정...
     return factory;
 }

payment-service/src/main/java/com/example/payment/kafka/InventoryEventConsumer.java (2)

34-42: 결제 멱등성 부족으로 중복 과금 위험

InventoryReservedEvent가 중복 수신되면 processPayment가 여러 번 실행되어 이중 과금될 수 있습니다.

권장 사항:

• orderId 기준 결제 단건 보장: Payment 테이블에 unique(orderId) 제약 조건 + 서비스에서 선조회
• PG 요청에 멱등키(orderId) 사용

 public void handleInventoryReserved(InventoryReservedEvent event) {
+    if (paymentService.isAlreadyProcessed(event.getOrderId())) {
+        log.info("이미 결제 처리된 주문 - orderId: {}", event.getOrderId());
+        return;
+    }
     log.info("📩 [Kafka Consumer] 재고 확보 성공 이벤트 수신 - orderId: {}, 결제 처리 시작",
             event.getOrderId());

---

44-50: 업무 실패와 시스템 실패를 구분하세요

모든 실패를 PaymentFailed로 처리하면 실제 과금 성공했으나 시스템 오류로 실패 이벤트가 발행되는 경우가 발생할 수 있습니다.

권장: 트랜잭셔널 아웃박스 패턴 사용 + PG 결과가 불명확한 경우 재시도/보류 상태로 구분하세요.

inventory-service/src/main/java/com/example/inventory/kafka/OrderEventConsumer.java (2)

39-42: 중복 소비로 재고 이중 차감 위험

동일 OrderCreatedEvent 재처리 시 reserveInventory가 중복 실행되어 재고가 두 번 차감될 수 있습니다.

권장:

• orderId를 포함한 멱등키로 1회만 차감되도록 설계
• Reservation 테이블에 unique(orderId, productId) 제약 조건 추가

-boolean success = inventoryService.reserveInventory(
-        event.getProductId(),
-        event.getQuantity()
-);
+boolean success = inventoryService.reserveInventory(
+        event.getOrderId(),
+        event.getProductId(),
+        event.getQuantity()
+);

---

74-77: 보상 트랜잭션 멱등성 부재로 재고 과증가 위험

PaymentFailedEvent 중복 수신 시 releaseInventory가 여러 번 실행되어 재고가 실제보다 늘어날 수 있습니다.

대응:

• 예약 레코드 기반 보상 (예약 존재 시에만 1회 복구)
• orderId 포함한 시그니처로 변경: releaseInventory(orderId, productId, qty)

-inventoryService.releaseInventory(
-        event.getProductId(),
-        event.getQuantity()
-);
+inventoryService.releaseInventory(
+        event.getOrderId(),
+        event.getProductId(),
+        event.getQuantity()
+);

delivery-service/src/main/java/com/example/delivery/kafka/DeliveryEventProducer.java (1)

92-94: Kafka 메시지 키로 toString() 사용은 순서 보장을 깨뜨립니다

주문 단위 순서를 보장하려면 키를 orderId로 고정해야 합니다. 또한 토픽을 외부화하세요.

+import org.springframework.beans.factory.annotation.Value;
+
 public class DeliveryEventProducer {
     private final KafkaTemplate<String, Object> kafkaTemplate;
-    private static final String TOPIC = "delivery-events";
+    @Value("${kafka.topic.delivery-events:delivery-events}")
+    private String topic;
 
     public void publishDeliveryStarted(Delivery delivery) {
         // ... event 생성
-        sendEvent(event);
+        String key = String.valueOf(delivery.getOrderId());
+        sendEvent(key, event);
     }
 
-    private void sendEvent(Object event) {
+    private void sendEvent(String key, Object event) {
         CompletableFuture<org.springframework.kafka.support.SendResult<String, Object>> future =
-                kafkaTemplate.send(TOPIC, event.toString(), event);
+                kafkaTemplate.send(topic, key, event);
         
         future.whenComplete((result, ex) -> {
             if (ex == null) {
-                log.info("✅ [Kafka Producer] 이벤트 발행 성공");
+                var md = result.getRecordMetadata();
+                log.info("✅ [Kafka Producer] 발행 성공 topic={}, partition={}, offset={}",
+                        md.topic(), md.partition(), md.offset());

delivery-service/src/main/java/com/example/delivery/service/DeliveryService.java (1)

40-41: 트랜잭션 커밋 전 비동기 작업 시작으로 가시성 문제 발생 가능

prepareDelivery의 트랜잭션이 커밋되기 전에 비동기 작업이 시작되면 startDeliveryAsync의 findById에서 레코드를 찾지 못할 수 있습니다.

트랜잭션 커밋 후 비동기 작업을 시작하도록 개선하세요:

+import org.springframework.transaction.support.TransactionSynchronization;
+import org.springframework.transaction.support.TransactionSynchronizationManager;
+
 @Transactional
 public Delivery prepareDelivery(Long orderId) {
     // ... 배송 준비 로직
     deliveryRepository.save(delivery);
     
-    // 배송 시작 스케줄링 (비동기 - 물류센터 출고 시뮬레이션)
-    startDeliveryAsync(delivery.getId());
+    // 트랜잭션 커밋 후 비동기 작업 시작
+    Long deliveryIdForAsync = delivery.getId();
+    TransactionSynchronizationManager.registerSynchronization(
+        new TransactionSynchronization() {
+            @Override
+            public void afterCommit() {
+                asyncProcessor.startDeliveryAsync(deliveryIdForAsync);
+            }
+        }
+    );
     
     return delivery;
 }

delivery-service/src/main/java/com/example/delivery/config/AsyncConfig.java (1)

18-27: Graceful shutdown 및 거부 정책 설정 필요

현재 구성에 누락된 프로덕션 필수 설정:

1. Graceful shutdown 미설정: 애플리케이션 종료 시 실행 중인 작업이 중단될 수 있습니다.
2. 거부 정책 미설정: 큐가 가득 차고 최대 스레드에 도달하면 기본 AbortPolicy가 예외를 던집니다.

다음 설정을 추가하세요:

 @Bean(name = "taskExecutor")
 public Executor taskExecutor() {
     ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
     executor.setCorePoolSize(5);
     executor.setMaxPoolSize(10);
     executor.setQueueCapacity(100);
     executor.setThreadNamePrefix("delivery-async-");
+    executor.setWaitForTasksToCompleteOnShutdown(true);
+    executor.setAwaitTerminationSeconds(60);
+    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
     executor.initialize();
     return executor;
 }

common/src/main/java/com/example/common/config/KafkaConsumerConfig.java (1)

46-58: 동시성 및 DLT 설정 추가 권장

에러 핸들러는 구성되었으나 다음 설정이 누락되었습니다:

1. 동시성 레벨 미설정: 기본값(1)으로 처리량 제한
2. DLT 미설정: 반복 실패 메시지 추적 불가

 @Bean
 public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory() {
     ConcurrentKafkaListenerContainerFactory<String, Object> factory =
             new ConcurrentKafkaListenerContainerFactory<>();
     factory.setConsumerFactory(consumerFactory());
+    factory.setConcurrency(3);  // 파티션 수에 맞춰 조정
-    factory.setCommonErrorHandler(new org.springframework.kafka.listener.DefaultErrorHandler(
-            new org.springframework.util.backoff.FixedBackOff(1000L, 3L)
-    ));
+    factory.setCommonErrorHandler(new DefaultErrorHandler(
+            new DeadLetterPublishingRecoverer(kafkaTemplate()),
+            new FixedBackOff(1000L, 3L)
+    ));
     return factory;
 }
+
+@Bean
+public KafkaTemplate<String, Object> kafkaTemplate() {
+    return new KafkaTemplate<>(producerFactory());
+}

delivery-service/src/main/java/com/example/delivery/kafka/PaymentEventConsumer.java (1)

34-42: 에러 처리 접근 방식 양호, 이벤트 발행 타이밍 개선 가능

ErrorHandler에 의존하는 에러 처리 방식은 적절합니다. 다만 이벤트 발행 타이밍을 개선할 수 있습니다.

현재는 트랜잭션 커밋 전에 이벤트가 발행될 수 있습니다. @TransactionalEventListener를 사용하여 커밋 후 발행을 보장하세요:

DeliveryService에서:

@TransactionalEventPublisher
public Delivery prepareDelivery(Long orderId) {
    // ... 배송 준비 로직
    deliveryRepository.save(delivery);
    
    // ApplicationEventPublisher로 도메인 이벤트 발행
    eventPublisher.publishEvent(new DeliveryPreparedDomainEvent(delivery));
    return delivery;
}

별도 리스너에서:

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onDeliveryPrepared(DeliveryPreparedDomainEvent event) {
    deliveryEventProducer.publishDeliveryPrepared(event.getDelivery());
}

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

order-service/src/main/java/com/example/order/kafka/SagaEventConsumer.java (1)

28-51: DLT 없이 자동 커밋을 유지하면 사가 이벤트가 유실됩니다.
현재 kafkaListenerContainerFactory 가 enable.auto.commit=true 인 기본 consumerFactory 를 공유하고, 리스너는 Acknowledgment 를 사용하지 않습니다. 이 상태에서는 DB 트랜잭션이 롤백되거나 OrderNotFoundException 이 발생해도 브로커 오프셋이 주기적으로 커밋되어 이벤트가 영구적으로 사라질 수 있습니다. 또한 DefaultErrorHandler 를 FixedBackOff 만으로 등록해 3회 재시도 후에는 DLT 로 보내지 않고 스킵하므로, 독성 메시지가 그대로 손실됩니다. 사가 오케스트레이션에선 이벤트 유실이 치명적이므로 동일 문제가 반복됩니다. enable.auto.commit 을 false 로 바꾸고 컨테이너 AckMode.MANUAL(또는 RECORD) 로 설정한 뒤 성공 처리 후에만 Acknowledgment.acknowledge() 호출하도록 시그니처를 (InventoryReservationFailedEvent failedEvent, Acknowledgment ack) 형태로 바꿔 주세요. 동시에 DeadLetterPublishingRecoverer 를 주입한 DefaultErrorHandler 로 실패 레코드를 별도 토픽(DLT)으로 옮기도록 조정해야 합니다. (예: KafkaConsumerConfig 에서 auto commit 비활성화 + DLT recoverer 추가, 리스너에서 성공 ack 및 예외 재던지기). 코딩 가이드라인 기준.

payment-service/src/main/java/com/example/payment/factory/PaymentGatewayFactory.java (1)

21-32: 불변 맵 사용으로 스레드 안전성 보장 필요

@PostConstruct를 사용하여 lazy 초기화 문제는 해결되었으나, strategyMap이 여전히 mutable HashMap입니다. 멀티스레드 환경에서 예상치 못한 동작이 발생할 수 있으므로 불변 맵으로 변경하는 것을 권장합니다.

-    private final Map<String, PaymentGatewayStrategy> strategyMap = new HashMap<>();
+    private Map<String, PaymentGatewayStrategy> strategyMap;

     @PostConstruct
     public void init() {
+        Map<String, PaymentGatewayStrategy> mutableMap = new HashMap<>();
         for (PaymentGatewayStrategy strategy : strategies) {
-            strategyMap.put(strategy.getGatewayType(), strategy);
+            mutableMap.put(strategy.getGatewayType(), strategy);
         }
+        this.strategyMap = Map.copyOf(mutableMap);
     }

payment-service/src/main/java/com/example/payment/service/PaymentService.java (6)

41-67: 트랜잭션 범위 최적화 필요

현재 @Transactional 내에서 외부 PG 호출이 이루어지고 있어 DB 커넥션을 불필요하게 오래 점유합니다. 외부 API 호출은 트랜잭션 밖에서 수행하고, DB 저장만 트랜잭션으로 처리하는 것을 권장합니다.

이를 위해 TransactionTemplate을 주입받아 사용하거나, 메서드를 분리하여 DB 저장 로직만 별도 트랜잭션 메서드로 구성할 수 있습니다.

---

41-67: 멱등성 보장 필요

동일한 orderId로 중복 결제 요청이 들어올 경우를 대비한 멱등성 보장이 필요합니다. DB에 order_id 유니크 제약을 추가하고, 이미 결제가 존재하는 경우 기존 결제를 반환하도록 처리하세요.

         log.info("[Payment Service] 결제 처리 요청 - orderId: {}, amount: {}, pgType: {}",
                 orderId, amount, pgType);
 
+        // 멱등성: 이미 결제 존재 시 재사용
+        Optional<Payment> existing = paymentRepository.findByOrderId(orderId);
+        if (existing.isPresent()) {
+            log.info("[Payment Service] 기존 결제 재사용 - orderId: {}", orderId);
+            return existing.get();
+        }
+
         // PG 전략 선택

---

41-67: 입력값 검증 누락

orderId, amount에 대한 null 체크와 유효성 검증이 없습니다. 음수나 0원 결제 요청을 사전에 차단해야 합니다.

     public Payment processPayment(Long orderId, Integer amount, String pgType) {
+        if (orderId == null || amount == null || amount <= 0) {
+            throw new IllegalArgumentException("유효하지 않은 결제 요청입니다");
+        }
+        
         log.info("[Payment Service] 결제 처리 요청 - orderId: {}, amount: {}, pgType: {}",
                 orderId, amount, pgType);

---

52-52: 하드코딩된 고객 정보 제거 필요

"CARD", "Customer", "[email protected]" 등이 하드코딩되어 있습니다. 실제 주문/고객 정보를 파라미터로 받도록 개선이 필요합니다.

---

55-61: PG 타입 저장 누락으로 취소 시 문제 발생 가능

Payment 엔티티에 사용된 PG 타입을 저장하지 않으면, 나중에 결제 취소 시 어떤 PG를 사용해야 하는지 알 수 없습니다. Payment 엔티티에 pgType 필드를 추가하고 저장해야 합니다.

-            Payment payment = new Payment(orderId, response.getPaymentId(), amount, "CARD");
+            Payment payment = new Payment(orderId, response.getPaymentId(), amount, "CARD", response.getPgType());
             paymentRepository.save(payment);

또한 Payment 엔티티 클래스와 DB 스키마에 pgType 필드 및 컬럼 추가가 필요합니다.

---

72-93: 취소 시 원래 사용된 PG를 사용해야 함

Line 80에서 기본 PG를 사용하여 취소하고 있는데, 이는 논리적 오류입니다. 결제 시 사용한 PG로 취소해야 합니다.

-        PaymentGatewayStrategy strategy = gatewayFactory.getStrategy(gatewayConfig.getDefaultGateway());
+        PaymentGatewayStrategy strategy = gatewayFactory.getStrategy(payment.getPgType());
         PaymentResponse response = strategy.cancelPayment(payment.getPaymentId());

이를 위해서는 앞서 언급한 대로 Payment 엔티티에 pgType 필드가 저장되어 있어야 합니다.

product-service/src/main/java/com/example/product/entity/Product.java (3)

15-24: @Setter 제거로 캡슐화 강화 권장

엔티티 클래스에 @Setter를 사용하면 모든 필드에 대한 public setter가 생성되어 도메인 로직을 우회할 수 있습니다. 예를 들어, setPrice()를 직접 호출하면 updatePrice() 메서드의 검증 로직을 건너뛸 수 있습니다.

 @Getter
-@Setter
 @NoArgsConstructor
 public class Product extends BaseEntity {

필요한 경우 특정 필드에만 명시적으로 setter를 정의하거나, 도메인 메서드를 통해 변경을 관리하세요.

---

72-81: 생성자에 유효성 검증 추가 필요

생성자에서 필드를 검증 없이 직접 할당하고 있습니다. updatePrice 메서드에는 가격 검증이 있지만 생성자에는 없어, 잘못된 상태의 Product 인스턴스가 생성될 수 있습니다.

     public Product(String name, String description, BigDecimal price,
                    Category category, String brand, String imageUrl) {
+        if (name == null || name.isBlank()) {
+            throw new IllegalArgumentException("상품명은 필수입니다");
+        }
+        if (price == null || price.compareTo(BigDecimal.ZERO) <= 0) {
+            throw new IllegalArgumentException("가격은 0보다 커야 합니다");
+        }
+        if (category == null) {
+            throw new IllegalArgumentException("카테고리는 필수입니다");
+        }
         this.name = name;
         this.description = description;
         this.price = price;
         this.category = category;
         this.brand = brand;
         this.imageUrl = imageUrl;
         this.active = true;
     }

---

100-105: null 체크 누락으로 NullPointerException 발생 가능

newPrice가 null인 경우 compareTo() 호출 시 NullPointerException이 발생합니다.

     public void updatePrice(BigDecimal newPrice) {
+        if (newPrice == null) {
+            throw new IllegalArgumentException("가격은 null일 수 없습니다");
+        }
         if (newPrice.compareTo(BigDecimal.ZERO) <= 0) {
             throw new InvalidProductPriceException(newPrice);
         }
         this.price = newPrice;
     }

delivery-service/src/main/java/com/example/delivery/service/DeliveryService.java (1)

42-42: @async 메서드 자기 호출은 비동기로 실행되지 않습니다

Line 42와 Line 69에서 같은 클래스 내 @Async 메서드를 직접 호출하면 Spring 프록시를 우회하여 동기적으로 실행됩니다.

권장 해결 방법:

별도 컴포넌트로 분리:

+@Component
+@RequiredArgsConstructor
+public class DeliveryAsyncProcessor {
+    private final DeliveryRepository deliveryRepository;
+    private final DeliveryEventProducer deliveryEventProducer;
+
+    @Async
+    @Transactional
+    public void startDeliveryAsync(Long deliveryId) {
+        // 기존 startDeliveryAsync 로직 이동
+    }
+
+    @Async
+    @Transactional
+    public void completeDeliveryAsync(Long deliveryId) {
+        // 기존 completeDeliveryAsync 로직 이동
+    }
+}

DeliveryService 수정:

 public class DeliveryService {
     private final DeliveryRepository deliveryRepository;
     private final DeliveryEventProducer deliveryEventProducer;
+    private final DeliveryAsyncProcessor asyncProcessor;

     public Delivery prepareDelivery(Long orderId) {
         // ...
-        startDeliveryAsync(delivery.getId());
+        asyncProcessor.startDeliveryAsync(delivery.getId());
         return delivery;
     }

Also applies to: 69-69

product-service/src/main/java/com/example/product/exception/ProductAlreadyDeactivatedException.java (1)

11-14: 문자열 포맷팅 개선을 고려해보세요.

현재 문자열 연결 연산자(+)를 사용하고 있지만, String.format()을 사용하면 가독성과 유지보수성이 향상됩니다.

다음과 같이 리팩터링할 수 있습니다:

     public ProductAlreadyDeactivatedException(Long productId) {
         super(ErrorCode.PRODUCT_ALREADY_DEACTIVATED,
-              "이미 비활성화된 상품입니다: " + productId);
+              String.format("이미 비활성화된 상품입니다: %d", productId));
     }

delivery-service/src/main/java/com/example/delivery/exception/DeliveryAlreadyStartedException.java (1)

11-14: 문자열 연결 대신 String.format() 사용 권장

성능과 가독성 향상을 위해 문자열 연결(+) 대신 String.format() 또는 Java 15+의 formatted() 메서드 사용을 권장합니다.

     public DeliveryAlreadyStartedException(String deliveryId) {
         super(ErrorCode.DELIVERY_ALREADY_STARTED,
-              "이미 배송이 시작되었습니다. 배송 ID: " + deliveryId);
+              String.format("이미 배송이 시작되었습니다. 배송 ID: %s", deliveryId));
     }

order-service/src/main/java/com/example/order/exception/OrderAlreadyCancelledException.java (1)

11-14: 문자열 연결 대신 String.format() 사용 권장

성능과 가독성을 위해 문자열 연결 연산자 대신 String.format()을 사용하세요.

     public OrderAlreadyCancelledException(Long orderId) {
         super(ErrorCode.ORDER_ALREADY_CANCELLED,
-              "이미 취소된 주문입니다: " + orderId);
+              String.format("이미 취소된 주문입니다: %d", orderId));
     }

payment-service/src/main/java/com/example/payment/exception/PaymentFailedException.java (1)

15-18: 문자열 연결 대신 String.format() 사용 권장

여러 파라미터를 결합할 때는 문자열 연결보다 String.format()이 가독성과 성능 면에서 더 우수합니다.

     public PaymentFailedException(Long orderId, String reason) {
         super(ErrorCode.PAYMENT_FAILED,
-              "결제 처리에 실패했습니다. 주문 ID: " + orderId + ", 사유: " + reason);
+              String.format("결제 처리에 실패했습니다. 주문 ID: %d, 사유: %s", orderId, reason));
     }

payment-service/src/main/java/com/example/payment/exception/UnsupportedPaymentGatewayException.java (1)

11-14: 문자열 연결 대신 String.format() 사용 권장

일관성과 가독성을 위해 문자열 포맷팅을 사용하세요.

     public UnsupportedPaymentGatewayException(String gatewayType) {
         super(ErrorCode.UNSUPPORTED_PAYMENT_GATEWAY,
-              "지원하지 않는 PG 타입입니다: " + gatewayType);
+              String.format("지원하지 않는 PG 타입입니다: %s", gatewayType));
     }

product-service/src/main/java/com/example/product/exception/InvalidProductPriceException.java (1)

13-16: 문자열 연결 대신 String.format() 사용 권장

BigDecimal 값을 포함한 메시지 생성 시 문자열 포맷팅을 사용하면 가독성이 향상됩니다.

     public InvalidProductPriceException(BigDecimal price) {
         super(ErrorCode.INVALID_PRODUCT_PRICE,
-              "가격은 0보다 커야 합니다. 입력된 가격: " + price);
+              String.format("가격은 0보다 커야 합니다. 입력된 가격: %s", price));
     }

order-service/src/main/java/com/example/order/exception/OrderNotFoundException.java (2)

11-13: 문자열 연결 대신 String.format() 사용 권장

일관성 있는 문자열 포맷팅을 위해 개선하세요.

     public OrderNotFoundException(Long orderId) {
-        super(ErrorCode.ORDER_NOT_FOUND, "주문을 찾을 수 없습니다: " + orderId);
+        super(ErrorCode.ORDER_NOT_FOUND, String.format("주문을 찾을 수 없습니다: %d", orderId));
     }

---

1-18: 선택적 개선: i18n 및 메시지 외부화 고려

현재 모든 예외 메시지가 한글로 하드코딩되어 있습니다. 향후 다국어 지원이나 메시지 관리의 유연성을 위해 다음을 고려해보세요:

1. 메시지 외부화: messages.properties 파일로 메시지 분리
2. MessageSource 활용: Spring의 MessageSource를 통한 i18n 지원
3. 메시지 템플릿 상수화: 재사용성과 일관성을 위해 메시지 템플릿을 상수로 관리

예시 구조:

// ErrorMessage.java (공통 모듈)
public class ErrorMessage {
    public static final String ORDER_NOT_FOUND = "주문을 찾을 수 없습니다: %d";
}

// OrderNotFoundException.java
public OrderNotFoundException(Long orderId) {
    super(ErrorCode.ORDER_NOT_FOUND, 
          String.format(ErrorMessage.ORDER_NOT_FOUND, orderId));
}

참고: 이는 즉시 필요한 변경은 아니며, 프로젝트의 i18n 요구사항에 따라 향후 적용을 고려하세요.

payment-service/src/main/java/com/example/payment/factory/PaymentGatewayFactory.java (1)

39-45: 입력값 검증 추가 권장

gatewayType이 null이거나 빈 문자열인 경우에 대한 명시적인 처리가 없습니다. 더 명확한 에러 메시지를 제공하기 위해 입력값 검증을 추가하는 것을 고려해보세요.

     public PaymentGatewayStrategy getStrategy(String gatewayType) {
+        if (gatewayType == null || gatewayType.isBlank()) {
+            throw new UnsupportedPaymentGatewayException("PG 타입이 null이거나 비어있습니다");
+        }
         PaymentGatewayStrategy strategy = strategyMap.get(gatewayType);
         if (strategy == null) {
             throw new UnsupportedPaymentGatewayException(gatewayType);
         }
         return strategy;
     }

delivery-service/src/main/java/com/example/delivery/service/DeliveryService.java (1)

122-128: 택배사 목록 외부화 권장

하드코딩된 택배사 목록을 설정 파일이나 DB로 관리하면 코드 수정 없이 택배사 추가/변경이 가능합니다.

예시 (application.yml):

delivery:
  carriers:
    - CJ대한통운
    - 한진택배
    - 로젠택배
    - 우체국택배

코드:

@Value("${delivery.carriers}")
private List<String> carriers;

private String selectCarrier() {
    return carriers.get((int) (Math.random() * carriers.size()));
}

product-service/src/main/java/com/example/product/service/ProductService.java (4)

89-100: JPA dirty checking으로 인해 save() 호출 불필요

Line 99의 productRepository.save(product) 호출은 불필요합니다. @Transactional 내에서 관리되는 엔티티는 변경 감지(dirty checking)를 통해 트랜잭션 커밋 시 자동으로 영속화됩니다.

 @Transactional
 public Product updatePrice(Long id, BigDecimal newPrice) {
     log.info("[Product Service] 가격 변경 - productId: {}, newPrice: {}", id, newPrice);
     
     Product product = getProductById(id);
     product.updatePrice(newPrice);
     
-    return productRepository.save(product);
+    return product;
 }

---

102-114: 메서드 재사용 및 불필요한 save() 호출

1. Line 109: findById를 직접 호출하는 대신 getProductById를 재사용하면 일관성이 향상됩니다.
2. Line 113: JPA dirty checking으로 인해 save() 호출이 불필요합니다.

 @Transactional
 public void deactivateProduct(Long id) {
     log.info("[Product Service] 상품 비활성화 - productId: {}", id);
     
-    Product product = productRepository.findById(id)
-            .orElseThrow(() -> new ProductNotFoundException(id));
+    Product product = getProductById(id);
     
     product.deactivate();
-    productRepository.save(product);
 }

---

116-139: DTO 클래스 분리 권장

Inner static 클래스로 정의된 CreateProductRequest를 별도 DTO 파일로 분리하면 가독성과 유지보수성이 향상됩니다.

제안 구조:

com.example.product.dto/
  ├── CreateProductRequest.java
  └── ProductResponse.java (이미 분리됨)

CreateProductRequest.java:

package com.example.product.dto;

import com.example.product.entity.Category;
import lombok.*;

import java.math.BigDecimal;

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class CreateProductRequest {
    private String name;
    private String description;
    private BigDecimal price;
    private Category category;
    private String brand;
    private String imageUrl;
}

---

28-46: 입력 검증 추가 권장

CreateProductRequest에 대한 검증 로직이 없습니다. 컨트롤러에서 @Valid를 사용하거나 서비스에서 검증을 수행하세요.

CreateProductRequest에 검증 어노테이션 추가:

+import jakarta.validation.constraints.*;
+
 @Getter
 @Setter
 @NoArgsConstructor
 public static class CreateProductRequest {
+    @NotBlank(message = "상품명은 필수입니다")
     private String name;
     
     private String description;
     
+    @NotNull(message = "가격은 필수입니다")
+    @DecimalMin(value = "0.0", inclusive = false, message = "가격은 0보다 커야 합니다")
     private BigDecimal price;
     
+    @NotNull(message = "카테고리는 필수입니다")
     private Category category;
     
     private String brand;
     private String imageUrl;
 }

컨트롤러에서 @Valid 사용:

 @PostMapping
-public ResponseEntity<ProductResponse> createProduct(@RequestBody CreateProductRequest request) {
+public ResponseEntity<ProductResponse> createProduct(@Valid @RequestBody CreateProductRequest request) {
     // ...
 }

Configuration used: Path: .coderabbit.yml

Review profile: CHILL